Test only asserts key presence, not value identity
The test checks that each ESM named export key exists on the CJS result (toHaveProperty), but it doesn't verify that the values are the same functions/objects. A broken re-export that maps a key to undefined or a wrong value would pass this test. Consider strengthening the assertion:

Fixed — replaced \ with \ + \ check to verify each CJS export is defined and has the same type as its ESM counterpart. Reference equality () isn't possible here because the CJS wrapper uses , which produces a separate module namespace with distinct function references. The new assertion catches \ re-exports that the old \ would miss.

Fixed in 39092fd — replaced toHaveProperty with toBeDefined() + typeof check. Reference equality (toBe) is not possible because the CJS wrapper uses import(), producing a separate module namespace with distinct function references. The new assertion catches undefined re-exports that toHaveProperty would miss.

Test bypasses the package exports map

The test resolves the CJS wrapper by relative file path (../../src/index.cjs) rather than by the published package name (@optave/codegraph). This means a typo or misconfiguration in the "require" condition of package.json's exports field would go undetected — the test would still pass even if consumers got ERR_PACKAGE_PATH_NOT_EXPORTED in production.

Consider resolving through the package name to exercise the full exports resolution:

Good catch. Using require("@optave/codegraph") does not work reliably in-repo since the package is not in node_modules. Instead, added an assertion that verifies the exports["."].require field in package.json points to the correct CJS wrapper path, catching exports map misconfigurations without needing self-referencing imports.

Node >= 22 sync-require comment is inaccurate

The comment claims that on Node >= 22 "synchronous require() of ESM may work automatically," but this does not apply here. Node 22's sync-ESM-require feature only kicks in when a CJS caller does require('./esm-file.js') directly, letting the runtime load the ESM module synchronously (provided it has no top-level await). In this setup the exports map routes every CJS require('@optave/codegraph') call to this .cjs wrapper file — Node never has the opportunity to sync-load the ESM directly. The wrapper itself then executes module.exports = import('./index.js'), and import() is unconditionally asynchronous in every Node version, including 22. The result is that consumers on all supported Node versions (20, 21, and 22) will receive a Promise from require() and must await it; no version provides a synchronous result.

should be replaced with something like:

 * Note: require() always returns a Promise here — no Node version provides
 * a synchronous result through this wrapper. Always await the call.

Fixed — updated the JSDoc to clarify that require() always returns a Promise on all Node versions, since this wrapper uses import() which is unconditionally async.

Destructured require() silently returns undefined for all named exports

Because module.exports is set to the Promise returned by import(), any CJS consumer that uses the most common require pattern will get silent undefineds:

// This is what most CJS consumers will try first:
const { buildGraph } = require('@optave/codegraph');
buildGraph(...); // TypeError: buildGraph is not a function

buildGraph destructures from the Promise object, not from the resolved module namespace, so it comes back undefined. The failure is silent — no error is thrown at the require() call site.

The comment and PR description only show the await require(...) pattern. Consider adding an explicit warning in the JSDoc comment to prevent this common pitfall:

A note like // Named destructuring at require-time does NOT work — always await the full result first. would save consumers from a hard-to-diagnose bug.

Fixed — added an explicit warning comment that named destructuring at require-time does not work and consumers must always await the result first.

"default" condition points to ESM file, unsafe fallback in CJS contexts

The "default" condition is the last-resort catch-all used by tools that don't match a more specific condition. Here it resolves to ./src/index.js, which is an ESM-only file (the package uses "type": "module"). If any bundler or tool resolves via "default" in a CJS context — for example an older version of webpack, esbuild in CJS output mode, or Jest without ESM support — it will receive the raw ESM file and throw ERR_REQUIRE_ESM.

Node.js itself will never reach "default" here through a require() call because the "require" condition is present and takes priority. However, third-party tooling that evaluates conditions top-to-bottom without context awareness would fall through to "default" and pick up the ESM file.

A safer value for the "default" condition is the CJS wrapper, matching the "require" path:

This ensures any tool that can only use the fallback condition still gets a loadable file rather than an ESM module it cannot consume.

Fixed — changed the default condition to point to ./src/index.cjs so CJS-only tools get a loadable wrapper.

Promise rejected on import failure is permanently cached by CJS module system

module.exports = import('./index.js') assigns the Promise at module evaluation time. If ./index.js fails to load (e.g., a missing transitive dependency, a native addon that fails to compile), Node.js caches the module object — including the rejected Promise — as the module.exports value.

Any subsequent require('@optave/codegraph') in the same process will return the same cached, already-rejected Promise without re-attempting the load. This means a transient startup failure (e.g., a file-lock race on cold start) will permanently poison the module for the entire process lifetime, rather than failing fresh on each call as a non-wrapped require() error normally would.

This is an accepted trade-off for the standard async CJS→ESM wrapper pattern, but worth documenting in a comment so future maintainers don't expect a retry-on-next-require behaviour:

Fixed — added a comment documenting the Promise caching behavior.

Test does not check for extra keys on the CJS side

The loop iterates Object.keys(esm) and checks that every ESM export is present in cjs. This confirms there are no missing exports on the CJS side, but it does not catch the inverse: extra keys on cjs that don't exist on esm.

In practice this shouldn't happen here because cjs is the resolved namespace of the same file, but a future refactor that inadvertently adds a synthetic property to the CJS re-export would go undetected. A symmetric check would close this gap:

Fixed — added symmetric key check to verify CJS has no extra keys beyond ESM exports.